Compute token estimate from character count

recordToolOutputObservability passes the UTF-8 byte length into estimateOutputTokensFromChars, but that heuristic is documented and named as chars/4. For non-ASCII responses (e.g., CJK or emoji-heavy outputs), byte length is larger than character count, so openchrome_tool_estimated_tokens is systematically inflated and no longer comparable across languages.

Useful? React with 👍 / 👎.

Normalize cache key version metric label

extractCacheStatus forwards keyVersion as an arbitrary string, and that value is later emitted as the key_version label in openchrome_cache_status_total without any bounding/normalization. If a tool reports per-request versions (hashes/timestamps), this introduces unbounded label cardinality and can degrade Prometheus memory/query performance.

Useful? React with 👍 / 👎.

Constrain cache status labels before emitting metrics

recordToolOutputObservability emits openchrome_cache_status_total with status taken directly from tool output via extractCacheStatus (only uppercased), so any tool that includes request-specific detail in cache status (for example reason strings or embedded IDs) will create unbounded label cardinality and degrade Prometheus memory/query performance. Please normalize this to a small allowlist (e.g., HIT/MISS/BYPASS/ERROR) or map unknown values to a fixed bucket before incrementing the counter.

Useful? React with 👍 / 👎.

Continue cache-status fallback instead of returning early

When raw is an object but does not contain a string status/cacheStatus, this early return null prevents the later structuredContent.cacheStatus fallback from running. In mixed-shape results (for example, cache: { keyVersion: "v2" } plus structuredContent.cacheStatus: "miss"), openchrome_cache_status_total is silently dropped even though a valid cache status is present.

Useful? React with 👍 / 👎.

Normalize compression mode labels before emitting metrics

recordToolOutputObservability forwards _compression.level directly into the mode label for openchrome_tool_compression_saved_bytes. Because MCPResult is free-form, any tool can return request-specific strings in _compression.level, which creates unbounded label cardinality and can degrade Prometheus memory/query performance once compression stats are emitted. Please map this label to a small allowlist (and bucket unknowns) before calling observe.

Useful? React with 👍 / 👎.

Bound tool labels before recording denied-call output metrics

recordToolOutputObservability is called on the scope-denied path before verifying that toolName is a registered tool, so a read-only API key can send arbitrary params.name values and create unbounded new time series in openchrome_tool_output_bytes / openchrome_tool_estimated_tokens (and potentially cache-status metrics). This introduces a cardinality-amplification vector from user input and can degrade Prometheus memory/query performance; normalize unknown names to a fixed bucket (e.g. unknown) or only emit these metrics after successful tool lookup.

Useful? React with 👍 / 👎.

Preserve compression stats before observing saved bytes

recordToolOutputObservability expects _compression.originalChars and _compression.compressedChars, but the success path currently rewrites _compression to { level, verbosity } before this method runs when compression.trackSavings is enabled. In that configuration, any tool-provided compression stats are discarded, so openchrome_tool_compression_saved_bytes never records even when a tool returns valid savings data. Please merge/retain existing _compression fields instead of replacing the object.

Useful? React with 👍 / 👎.

Count full uncompressed response when reporting delta savings

_compression.originalChars is set from outputText.length, but the non-delta DOM response for the same call is outputText + domPaginationSection. When includePagination is left at its default (true) and pagination metadata is non-empty, this undercounts the baseline and can make originalChars <= compressedChars, so openchrome_tool_compression_saved_bytes is underreported or dropped even when delta compression actually saved bytes.

Useful? React with 👍 / 👎.

Convert compression savings metric to true byte deltas

openchrome_tool_compression_saved_bytes is recorded from originalChars - compressedChars, but those _compression fields are character counts (for example read_page sets them from .length). For non-ASCII output (CJK, emoji, etc.), character deltas can differ substantially from UTF-8 byte deltas, so this metric reports incorrect units and can mislead dashboards/alerts that depend on byte savings. Compute the delta from UTF-8 byte lengths (or rename the metric to chars) before observing it.

Useful? React with 👍 / 👎.

Compute original delta size from full DOM response

In the delta path, _compression.originalChars is derived from outputText.length, but the fallback non-delta DOM response includes nodeRefsBlock and optional pagination text as well. On pages with large [node_refs] sections (or pagination metadata), this underestimates the baseline size and can hide real compression savings in observability metrics. Use the same full-response text shape used by the non-delta return when calculating the original size.

Useful? React with 👍 / 👎.

Measure compression savings in bytes before reporting

This metric is named openchrome_tool_compression_saved_bytes, but it records originalChars - compressedChars from _compression. Since these values are currently based on string .length (UTF-16 code units), responses containing multi-byte UTF-8 characters will report incorrect byte savings. Convert both values to UTF-8 byte lengths (or rename the metric) so dashboards reflect actual payload reduction.

Useful? React with 👍 / 👎.

Compute delta compression savings from comparable payloads

The _compression metadata for read_page delta responses currently compares originalChars from outputText.length against compressedChars from compressedText.length, but compressedText includes nodeRefsBlock/pagination sections while originalChars does not. In calls where those shared sections are non-trivial, this undercounts (or can invert) savings, which then suppresses or distorts openchrome_tool_compression_saved_bytes in recordToolOutputObservability. This makes the new observability metrics inaccurate specifically for DOM delta mode responses with larger node-ref or pagination blocks.

Useful? React with 👍 / 👎.

Bucket unregistered tool labels before emitting metrics

recordToolOutputObservability emits tool labels using raw toolName, but this function is now called on tenant/scope-denied paths before tool lookup (src/mcp-server.ts around lines 1295-1342), where toolName comes directly from request input. That lets callers generate unbounded time-series cardinality by sending many distinct bogus tool names, which can exhaust metrics memory and scrape performance; unregistered names should be normalized to a bounded value (e.g., unknown) before emitting openchrome_tool_output_bytes, openchrome_tool_estimated_tokens, openchrome_tool_compression_saved_bytes, and openchrome_cache_status_total.

Useful? React with 👍 / 👎.